The invention relates to controlling asynchronous updates to a register in a computer system and in particular, to protecting hardware asynchronous updates to a register that is simultaneously modifiable by software.
There are many structures within a computer system that can be read and written by both hardware and software. These structures generally exist for the purpose of exchanging information (e.g., status, interrupts) between hardware and software. Due to the asynchronous nature of these structures, special attention must be paid to how software updates are performed. A typical register will hold more than one independently updateable field. Hardware updates to each field are automatically independent, but software updates to each field may not be independent. For example, a software update to such a register may include performing a “read-write-modify” operation. This operation instructs the software to read the register. If, in the time between the read and the write, the hardware has asynchronously updated a field, the hardware update will be lost (overwritten) by the old (stale) value at the completion of the read-modify-write operation.
One approach to handling the problem of asynchronous updates is to break up the register on field boundaries into separately accessible registers. This approach requires more registers, which may not always be available in the hardware system. Another approach to handling the problem of asynchronous updates is to add locks to fields within the register. Software would then be responsible for setting and resetting locks before and after the software updates. This approach is not ideal because it requires additional software instructions to be executed for each software update to a register. The execution of the extra instructions may cause longer execution times. A third approach to handling the problem of asynchronous updates is to create special instructions and hardware for accessing these registers such that a field can be manipulated independently. A drawback of this approach is that special instructions must be written and accessed to perform data manipulation. A further approach is to attempt to place critical bits into registers that don't get a lot of read-modify-write traffic. This works to a point, but will still fail, just not as often. In addition, new software code (e.g., millicode) is created on a frequent basis. Therefore, a register that is thought at one point in time to have low traffic, may not have low traffic at a later time. In addition to the drawbacks noted above, none of these approaches to handling the problem of asynchronous updates provides a system where registers are generally accessible by software, such that the software can perform a single operation to read, write and/or read-write-modify the register.